IBIS Macromodel Task Group Meeting date: 05 September 2017 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan * Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: Randy Wolff Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Curtis noted that EDICON in Boston runs from September 11 until September 13. Curtis and Mike L. said they would be at EDICON and unavailable for the next ATM meeting. Arpad asked if we should cancel the ATM meeting on September 12. Curtis and Mike L. were the only ones unable to attend, so the group decided to hold the September 12 meeting as scheduled. Arpad noted that he would need a volunteer to take the minutes at that meeting. - Arpad noted that Michael M. had sent a private email regarding samples/bit issues with AMI models. - Michael M.: We occasionally run into issues with poor documentation regarding an AMI model's samples/bit requirements. - I'm wondering if we could have a Reserved parameter (Usage Info) to convey any samples/bit requirements. - This might help with model-to-model compatibility and tool-to-tool agreement. - Walter: We had long discussions about samples/bit years ago. - We had proposed just such a parameter so the model could report any samples/bit constraints. - That BIRD was rejected. - EDA tools could easily implement a "torque converter" to translate between models with different samples/bit requirements. - The BIRD was not approved because it's just as trivial for the model to implement the torque converter itself. - That's just a review of the status and history of this topic. - Arpad: At the time, the decision was that all models should work at all sample rates... famous last words. - Walter: That decision was to make it easy for tool vendors. - But there are currently models out there that only work at certain samples/bit. - There's currently no way to convey that information to the tool. - Arpad: We've seen some models that have different samples/bit requirements at different rates. - We often see an inverse relationship - at lower bit rates the model needs more samples/bit. - It might be useful to have different bit rate ranges that have an associated samples/bit. - Walter: No, it should all be Nyquist related. - If you're at 10GHz, all you should really need in order to simulate is 8 or 16 samples per bit, because above that you're so far above the Nyquist frequency it doesn't matter. - So models shouldn't behave that way, but some people think that way. - Mike L.: Looking at some model documentation, some models do express a requirement to use a given samples/bit at a certain data rate. - Those seem to be looking to control or enforce some max sample interval. - That does suggest something internal to the model that has some fixed time constant. - Other models are like Walter described and really just seem hard coded and designed to work at one particular samples/bit. - Right now the IBIS spec just says that models should work at any samples/bit. - How about 1 sample per bit? ;-) - Is it okay if a tool or model only wants to work in powers of two? - Arpad: Just last week I ran into a model that was simulating correctly (no crashes, errors, etc.), but below 8Gbps at 32 samples per bit the eye was closed and at 64 samples per bit the eye was wide open. - The model obviously had some sample related dependency, but how would the user know? - Mike L.: I test a lot of models. Unfortunately, many show different, though reasonable looking, results with different samples/bit. - Michael M.: As Walter noted, it is possible for model makers to make their models work for all (reasonable) samples/bit, but there are lots of models out there that don't. - Perhaps we could add a parameter that would allow the model maker to report that requirement instead of having to rewrite their model. - I will think about what to propose. - Arpad and Walter noted that the Interconnect Task Group is again discussing whether and how node 0 should be available for referencing. They asked people to follow the Interconnect Task Group emails if interested. ------------- Review of ARs: - Radek to send out an updated BIRD 158.6 draft 5 as discussed. - Not yet done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Minutes from the previous meeting had not been posted in time for review. ------------- New Discussion: BIRD158.6: - Arpad: We did not get the updated document from Radek. - Discussion deferred. C_comp Improvements: - Arpad: Randy is not here either. Walter, do you have any updates on this? - Walter: I sent an email to Arpad, Bob R., and Randy. - End result is I'd like to make an I/O device have I/V curves driving mode that are entirely independent of the I/V curves for receiving mode. - I think that makes a lot of sense if the protection circuits could be different for driving mode and receiving mode. I've been told that this is physically possible, and this is currently a limitation of IBIS. - I think having separate I/V tables for driving and receiving mode makes it a lot simpler. - Arpad: Why are existing Submodels not sufficient for you to have different currents under different modes? - Walter: Submodels involve adding currents. - I want a set of fully independent curves. - Right now the way you'd measure an I/O is you turn it off and generate your I/V curves for the clamps. Then you turn it on and measure your Pullup and Pulldown curves. But then you have to subtract the clamp curves from the Pullup and Pulldown curves. When the clamps are actually different between driving and receiving modes then this gets messy. - Arpad: When you talk about independent curves for driving and receiving mode, are you talking about statically choosing a mode before the simulation or are you also interested in dynamically switching like Randy and I presented at DesignCon? - Walter: No, I'm not interested in bus turnaround. That's a whole new bag of worms with too many complications for IBIS to capture. - Bob R.: The question is whether to support independent clamp tables vs. the existing Submodel mechanism. People use Submodel now. Though it does involve de-embedding some currents to make the model, it's a workable solution. - I don't like separate I/V tables as a solution. - Walter: We need to wait for Randy and to discuss specific examples. - Arpad: Yes, we need a firm proposal to discuss. New BIRDs from Editorial Task Group: (Item 9) - Arpad: Do we have an update on this from Bob R. and Radek? - Bob R.: We haven't done anything with it lately. - It should stay on the agenda. - We decided to postpone this work until 7.1. - Walter: Motion to table item 9. - Bob R.: Second. - Arpad: Anyone opposed? [no one opposed - Item tabled] - Curtis: Motion to adjourn. - Michael M.: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 12 September 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives